HPAVC/HPAVC CD-ROM.iso/CIS_GAME.ARJ/QWOLF3.THD

Text File | 1993-07-01 | 103KB | 2,066 lines

___________________________ Subj: Wolf3D Engine ___________________________

Fm: rod lentz 71163,57                         # 337322
To: Teut Weidemann 100022,2466 (X)             Date: 19-Apr-93  04:58:14

    I've been working on this in a 3d (raycasting) context; walls
are easy, of course, but I'm having a little problem with other
objects.
    Should I deal with a list of objects which [partially] occupy
each cell, for minimizing searching ?  This would need a lot more
memory, but I suspect should be worth it.
    I'm also having some trouble finding what angle a ray hits
an object; I need it to be related to some constant angle for any
view, i.e. possibly the normal at the objects center to the viewer.
    Any suggestions ?

        - Rod
...........................................................................

Fm: Teut Weidemann 100022,2466                 # 337338
To: rod lentz 71163,57                         Date: 19-Apr-93  06:51:46

Ah, so you were talking about 3D programming. For a game? If so, most people
use the norm vector which they relate to their light source and the viewer.
Most games out there I think dont use "ray tracing" but a form called
radiosity (is that right?), ie. the objects are mesauring their surface pixel
by pixel with the light source instead of shooting thousands of rays through
a scene. 3D is far more ocmlicated for "real time" games than it seems. A
friend of mine (David Braben, Author of Elite, Virus and some others) told me
a quote: "If you want to have speed in a 3D action game you have to move far
away from conventional 3D math."

Teut
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 358313
To: R.MORLEN 73167,3263 (X)                    Date: 19-May-93  15:08:32

The chief difference between ray tracing and ray casting is this: In ray
tracing, a ray is cast for every pixel in the viewport. In ray casting, a ray
is cast for every vertical _column_ of pixels in the viewport. What you do
with that ray is up to you: there are a number of clever techniques for
determining the path of the ray and for generating pixel information from
that path. And more techniques seem to be discovered every week. Done
correctly, you don't have to worry about scaling bitmaps; it happens
automatically, as in raytracing, when the intersection of the ray with a
pixel or column of pixels is calculated.

The main problem with ray casting vis a vis ray tracing is that there are
limits on the type of scenery that can be depicted: fixed-size rectangles
oriented at right angles to one another seem to work best. (Variations are
possible, but usually with a speed penalty attached). The main advantage is
that the number of rays to be cast is reduced by a couple of orders of
magnitude, which allows for real-time animation. And the simplified scenery
makes a number of optimizations possible.

--Chris
...........................................................................

Fm: Lary Myers 76004,1574                      # 358865
To: All                                        Date: 20-May-93  12:17:52

Here is the basic process I am using if anyone has any initial comments or
ideas before they see X.ZIP. From the players X and Y coordinates I cast a
ray out in order to look for a hit on a wall. The ray is first cast with the
X coordinate fixed at 64 (the dimension of each square in the map grid is
64x64) and the Y coordinate calculated based on the current angle being cast
(ie. If the player is facing at angle zero then the first angle I check is 45
degrees to the left or angle 315). Each X wall is checked to see if a
non-zero value exist or not. If so then an Xdistance is determined by C2 = A2
+ B2 formula. Then the same is done for the Y walls except this time the Y
coordinate is changed by 64 and the X coordinate is calculated based on the
angle. When all this is said and done there will be four meaningful values,
an Xcolor, Xdistance, a Ycolor and a Ydistance. (I am only using colors now
for the walls, later these values will be indexes to bitmaps). Whichever
distance is shorter is used to draw the wall. The final distance is then
multiplied by the cosine of the current angle (say 45) and used to determine
the height of the wall (looked up from a distance table created at startup).
This is where the first anomaly appears. I see that some portions of the
walls are higher or lower than other portions depending on the distance and
angle the player is at. If the cosine adjustment is removed the spikes or
divits go away but the bowed or fisheye effect is seen on the walls (since
the rays are cast out from a single point). So far everything is written in C
and hasn't been optimized fully yet, still I am getting good response from
the rest of the process, I just can't get my walls to appear flat!! The
pattern of the spikes is very organized and it sure looks like round-off
error in the tables, but.... Is this enough information for anyone to suggest
a course to try? Any comments would be appreciated.....

Lary
...........................................................................

Fm: Mark 'SAM' Baker 100025,444                # 358946
To: Lary Myers 76004,1574 (X)                  Date: 20-May-93  16:29:02

Could it be that some of your angles are fractional. I would assume that your
cosine table is only based on integer angles. This would give you a small
error, and when you multiply by the distance the error becomes more
significant.
This would give you a more obvious error at greater distances; and also at
angles closer to 45 degree margins.

                                                Mark
...........................................................................

Fm: Lary Myers 76004,1574                      # 359220
To: Mark 'SAM' Baker 100025,444 (X)            Date: 21-May-93  00:19:34

Mark, This is what I'm thinking also - I using a table of longs which keep
most of the fractional part. I take the cosine of the angle and multiply it
by 65536 (or a shift of 16 bits) so that the number (.707106 in the case of
45 degrees) is changed to 46341 when multiplied. I'm still wondering if this
is enough though. When I get the distance (say for example 131) I mulitply
that by the long cosine value and then shift it back down 16 bits to get the
final distance (in this case 92). But you're right, the errors do appear in a
certain pattern. Any suggestions on a way around this?
Thanks - Lary :)
...........................................................................

Fm: Mark 'SAM' Baker 100025,444                # 359277
To: Lary Myers 76004,1574                      Date: 21-May-93  01:53:48

The obvious solution for accuracy is to do the calc at run time,  rather than
use a table; but this will obviously affect your speed drastically.
You could try guesstimating the fractional part of the angle, and taking the
proportional value between the two integer angles.
eg. 47.4 degrees
cos 47 = .6820
cos 48 = .6691

cos angle = .6820 + ((.6691-.6820) x (angle - int(angle)))

                                Mark
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 360118
To: all                                        Date: 22-May-93  10:30:43

The following new files are now available in LIBRARY 11 (Game Design):

[76004,1574]
X1.ZIP/Bin       36012     21-May-93

  Title   : 3D Raycasting Engine Beta version 2 (IBM)
  Keywords: WOFL 3D RAYCASTING GRAPHICS SOURCE IBM

  Here is an updated zip file with the Wolf 3d style engine that I have
  been working on. This version has two problems described in the readme
  file. This is a very crude beginning and as a long way to go. If anyone can
  see where the problems are please let me know. The approach I took may be
  way out in left field so any comments/suggestions would be appreciated.
...........................................................................

Fm: LAWRENCE M MATTA 70751,1424                # 362000
To: Lary Myers 76004,1574 (X)                  Date: 24-May-93  17:57:19

Lary,
Have you tried reducing the half angle of the view from 45 degrees to 30?  I
think this will greatly reduce the distortion.  Of course, it also reduces
what you see at any given time, but you can't have everything!
Larry
...........................................................................

Fm: Lary Myers 76004,1574                      # 362099
To: LAWRENCE M MATTA 70751,1424 (X)            Date: 24-May-93  19:51:19

Larry, Yep - tried a variety of angles. Do you mean to reduce the angle to 30
and not use the cosine correction on the distance? I need to start keeping a
log of all the variations that I've tried, I'm sure that I've gone through
several iterations more than once! I'll try the 30 degrees, it means
recalcing the trig tables for a different total value (right now its 2048
increments for 360 degrees). I keep looking at Wolf and Ken's labryinth and
they both look like 90 degree (or about) views. There has to be a happy
medium to show this at but I haven't hit upon it yet. Thanks for the
suggestion. - Lary
...........................................................................

Fm: LAWRENCE M MATTA 70751,1424                # 362736
To: Lary Myers 76004,1574 (X)                  Date: 25-May-93  18:29:59

Well, I'm using about 50 degrees total angle, and I don't get much
distortion, but I can't reproduce the WOLF3D display with that field.  I need
to do some playing around when I ahve the time and see what I can  come up
with.  Keep me informed of your progress!
Larry
...........................................................................

Fm: Ed Goldman 72630,2763                      # 364897
To: Lary Myers 76004,1574 (X)                  Date: 29-May-93  12:11:21

Lary,

Yeah, I thought this engine worked a bit differently from a flight sim type
engine. Looking forward to your future incarnations of it.

In case anyone's interested there's a pretty good game designers ftp site on
the internet at ftp.netcom.com in /pub/profile/games/msdos.  The Abrash
articles are all conveniently in one zip file called graphprg.zip.  There's
about 20 articles and source code (Borland C and TASM).  There's another zip
contained within it called xsharp.zip.  This is his final 3d engine which
includes shading techniques, texture mapping, a program to automatically
generate the vertices of a sphere.  It's all built on Xmode.  Other stuff is
fast (Wu) anitaliasing, 386 optimized fixed point mult and div, Sierra DAC,
....  If there's interest I could try to upload it here (I've had some
sporadic com problems with large downloads on Cserve n the OS/2 2.1 beta that
I'm running, so don't know if I'll be able).

In the meantime, on a new thread, I'm thinking about Ghourad Shading
techniques and the math involved.  Looking for comments and I have some
questions. Follow me there if you will ....

-edg-
...........................................................................

Fm: Lary Myers 76004,1574                      # 364526
To: Chris Lampton 76711,301 (X)                Date: 28-May-93  18:34:42

Chris,
  Do you have any ideas on how to maintain accuracy when computing the square
root of the distance and then multiplying that by the cosine of the angle? I
have practically everything else in fixed point now but as soon as I mess
with that distance the spikes return. Heres a code snippet of what I'm doing;

  WallDistance = (xDelta * xDelta) + (yDelta * yDelta)     <- all floats
  ....
  WallDistance = sqrt(WallDistance)
  WallDistance = WallDistance * CosTable[angle]   <- Table is floatsl
  WallDistance = ceil(WallDistance + 0.5) <- Roundup

WallDistance is now the number used to look up the height in the distance
table. This is the code running in the version you have. I try to convert
this to fixed point and no sale. I lose the accuracy! Let me know if you can
see any solutions to my latest delemma.
   Had a chance to compare speeds yet? At least now I'm closing in on a
non-floating point version, if I can play some tricks with the distances then
I'll have it. Thanks - Lary
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 364660
To: Lary Myers 76004,1574 (X)                  Date: 28-May-93  22:58:57

I'm not sure why you're having an accuracy problem with the square root and
the cosine. I haven't had such a problem (knock wood!), though I don't rule
out the possibility that I'll run into it. Are you having the problem _only_
with fixed point or with floating point as well? If it's only with fixed
point, then the problem may be with the fixed point routines themselves. How
do they work? The simple fixed point stuff that I included in FOF is fairly
low precision; to get better without sacrificing speed, you pretty much need
to work with 32-bit registers. If you aren't, that might be the problem. Or
maybe you're shifting digits off one end of a register without realizing it.
Remember, for instance, that the dividend in fixed point division must be
shifted to the left _before_ the division, so you don't lose digits off the
righthand end when the division shifts them back the other way. And how are
you doing the fixed point sqrt()?

>Had a chance to compare speeds yet?

With your latest version? I haven't seen it yet. It takes a couple of days
for files to find their way into the LIBs here and yours doesn't seem to have
arrived yet. It'll be difficult to compare speeds with my own engine, since
(a) I haven't tried animating mine yet; and (b) mine does fully bitmapped
walls and floors. (I could take that back out for comparison purposes if you
haven't added that to your own code yet, but that's where the real
optimizations are going to be needed.) It's still fairly slow right now, but
I haven't added a lot of optimizations yet.
--Chris
...........................................................................

Fm: Lary Myers 76004,1574                      # 364912
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 29-May-93  12:34:45

Chris, Thanks for the reply. No need to go any further now!!!! Its working g
great and doesn't contain a single line of floating point anymore! Whew! Yes,
the fixed point problem was just what you thought, losing the digit off the
end. Speed comparison: Yes, the X2.ZIP does do bitmap walls so no need to
take that out of yours. But don't bother doing the speed compare with X2
since I'll be uploading X3 soon and that is the one to check out. Should be
no difference whether a math chip or not. Re: fixed point square root - I'm
not doing square roots anymore at all! Found a way to do it another way that
doesn't need it. Thanks again for the help and I'll get X3.ZIP up as soon as
I can. (Memorial weekend is here.....) Lary :)
...........................................................................

Fm: LAWRENCE M MATTA 70751,1424                # 365542
To: Lary Myers 76004,1574 (X)                  Date: 30-May-93  14:00:14

I cast rays from a single point, through a virtual window, and then out to
the object.  The window coresponds to the screen.  I just put on the screen
what intersects with the window.  I dont know how clear that was, but it
makes sense if you draw a picture.  So, i suppose I'm drawing the projection
of the image on a plane that is a fixed distance in fron of the observer.
I'm playing with the speed now, and not worrying about the view field right
now.  After I get the trig tables set up, I'll try uploading a copy for
general discussion.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 366305
To: John W. Ratcliff 70253,3237 (X)            Date: 31-May-93  16:40:05

John:

I don't think Lary intended for the X1 engine and its successors to be a
full-tilt polygon engine. The view-slice system that he's using -- what's now
being called a raycasting system -- is a quick and dirty method of performing
intensive texture mapping over large areas in a minimal time. (Lary tells me
that he's added the texture mapping in the next draft of the engine, which
may or may not have appeared in the LIBs by this time.) The price of this
approach is that the types of objects and environments that can be depicted
is extremely limited -- fixed-size bitmapped rectangles oriented at right
angles to one another (and to the view plane) work best. Which is why
raycasting engines tend to be used to create maze-like interior environments
a la WOLF3D, with bitmapped floors, walls, and ceilings, in games that
emphasize high-speed animation. Within that limited domain, it would be
interesting to see if the raycasting approach can outrun a generalized
polygon engine, assuming maximum optimization for both. My guess is that it
would. Perhaps somebody could put together a pair of benchmarks, depicting an
environment deliberately chosen to take advantage of the strengths of
raycasting....
--Chris
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 366540
To: Marc a Gaudet 70724,636 (X)                Date: 31-May-93  21:39:17

Quadtrees (and their three-dimensional equivalent, octrees) work best with
raytracing and raycasting systems, where you need to search a two- or
three-dimensional space for collisions between surfaces and visual rays. By
trivially dismissing large volumes of empty space, they can reduce time
otherwise spent looking for collisions. Some raytracers use the octree
approach. A quadtree variant might conceivably be useful in raycasting
programs using a two-dimensional representation of a three-dimensional
interior environment. In fact, the tiled environment used in most raycasting
systems can be looked at as a kind of variation on the quadtree, with area
tiles further breaking down into grids of pixels and (perhaps) walls and
height fields.

They would be a lot less useful for a polygon-fill engine, since such engines
tend to be more object-oriented than space-oriented -- i.e. they maintain
lists of objects which are in turn lists of polygons which have spatial
coordinates associated with them. Polygon-fill engines have no need to search
space for collisions with visual rays (except in a limited way during hidden
surface removal) and probably wouldn't benefit from a data structure designed
to optimize searches.
--Chris
...........................................................................

Fm: Lary Myers 76004,1574                      # 367565
To: All                                        Date: 02-Jun-93  10:47:19

Another area of discussion: Anyone have any ideas on how to do moving objects
in the ray casting environment? Static objects occupy a map square just like
walls so they are "easier" to project. Moving objects will dynamically change
location, direction, etc and will no longer be on the nice 90 degree grid
that made the walls  locatable with the ray casting routines. Any thoughts?

P.S. The latest update (X3.ZIP) has been uploaded so look for it soon! It
supersedes X1 and X2 (which hasn't become available yet).

Lary
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 367681
To: Lary Myers 76004,1574 (X)                  Date: 02-Jun-93  14:56:27

Here's one way to handle it: First of all, you need a coordinate system that
has a finer resolution than the tiles themselves. (You may already be doing
this.) Give each object a pair of x,y coordinates defined in terms of that
finer coordinate system. Allow objects to overlap more than one tile. Each
tile overlapped by a sprite can then be given a pointer to that sprite, to
make it easy to find the sprite. For drawing purposes, use the sprite
coordinates, not the tile coordinates.

--Chris
...........................................................................

Fm: Lary Myers 76004,1574                      # 367966
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 02-Jun-93  21:57:02

Okay Chris, I'm with you. I am currently setting a bit in the tile to
stipulate that an object is present so the current ray casting picks it right
up. The question I have is that, even with a finer resolution, I would still
get a corner effect when looking at the object diagonally - yes? The X3 that
was uploaded has objects partially implemented but had to do so by knowing
when to ignore the X ray or the Y ray. It appeared it was going to work but
there are overlap problems when crossing the boundary between using X or Y.
Also, wouldn't the finer coordinates mean casting a third ray since the
current two are optimized for the tile coordinates? I think I'm on the track
of a method that will handle both stationary and moving objects, with the
exception of knowing what column in the bitmap to draw. If I can figure that
out then it will wipe out two problems at once.

Lary
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 368102
To: Lary Myers 76004,1574 (X)                  Date: 03-Jun-93  03:42:27

I'm not sure why you're getting the "corner effect," but obviously it relates
to the way in which you're casting for the walls. Sounds like you may want to
rethink the casting so that it will work both walls and objects.

--Chris
...........................................................................

Fm: Lary Myers 76004,1574                      # 368764
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 04-Jun-93  02:13:23

Been thinking about your comment to rethink the casting to pick out the
objects. Don't know.... The ray cast routines are optimized based on the size
of the map grid and they seem to be very fast. What I'm leaning towards is
finding a way to display an object at different angles with the object having
x,y coordinates somewhere on the map. This will mean looking through the list
of objects to find the visible ones but it would allow independent movement
of the objects on other than grid boundaries. Any thoughts? This whole
process is similiar to normal 3D projection except the distance from an x,y
point to your x,y point is being used to determine the height of the object.
The ray casting inherently (sp?) took care of width scaling simply because
the further away the wall the less rays intersected it. This would not be the
case with independent objects since ray casting wouldn't be used.
Lary
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 369041
To: Lary Myers 76004,1574 (X)                  Date: 04-Jun-93  16:21:03

I just took a look at your X3 engine. Very nice! The speed is much improved
from the first version. It moves along nicely even on my 16mhz machine. (We
authors can't afford to upgrade very often. <g>) By contrast, I never made it
out of the room (or managed to rotate 180 degrees) in the first version.
There's still room for speed improvement -- it's not as fast on my machine as
KEN'S LABYRINTH or WOLF3D -- but on a faster machine the current version is
probably more than adequate.

Assuming that the trees scattered throughout the maze are objects, I don't
see any problem with them. I _thought_ I saw some flattening along the
righthand side of the tree, but I'm pretty sure that was just the way the
tile was drawn. If I had a clearer idea of what the object problem is and
what's causing it, I might be able to make a suggestion as to how you could
fix it, but as it stands I have no idea. You don't necessarily need to rework
your wallcasting, but if it's causing a problem with the objects, you need
some way of making them compatible with it. How are the objects stored? As
non-rotating bitmaps with transparency?

--Chris

p.s. After reading TIM's note, I went back and looked at the trees again.
There are a few cases where they seem to jump from one side of the floor tile
to the other. Is that the problem you're talking about?
...........................................................................

Fm: Lary Myers 76004,1574                      # 369117
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 04-Jun-93  18:45:41

Hi Chris - The object problem relates to what column of the object bitmap to
draw. The objects are stored the same as the walls, in a 64x64 bitmap with
color zero being transparent. When I'm casting a ray and come across a square
in the map that contains an object I have to determine which column of the
object to draw. For walls this was no problem since I wanted to use column
0-63 of the X side and 0-63 of the Y side. For objects, if I cast (for
example) 64 rays that intersect with the x side then I would have 64 columns
there, now if 64 rays are cast that intersect with the y side that would give
an additional 64 columns of the object, which is what I don't want. What I
need to do is determine from 0-63 columns of the object no matter which ray
intersects with the square. This is probably as clear as mud but the limited
bandwidths of mail causes sacrifices.... Anyway - Do you happen to have the
equation for determining the distance from a point to a line handy? I had it
in one of my references but don't have the book anymore.

Lary
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 367850
To: Lary Myers 76004,1574 (X)                  Date: 02-Jun-93  19:26:15

Hmm, good question. How about drawing the objects as seen from several
different angles, and continuing to treat them as wall tiles? This is similar
to the system used in games like Eye of the Beholder, and the last two Might
and Magics: the creatures move one full square at a time. It would be nice to
have finer movement, so I'd try to combine it with Chris' idea for a grid at
a finer resolution overlayed on the map squares. One twist involves clipping.
If you handle the object during a second scan pass, then you have to clip it
to whatever walls are between it and the point of view, whereas drawing the
object at the same time as the walls would make clipping easier, but would
involve integrating both coordinate systems.

                                                        --Mark
...........................................................................

Fm: Lary Myers 76004,1574                      # 367970
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 02-Jun-93  22:00:34

The finer movement is the way I want to go. I did have the objects treated as
wall tiles at first but the corner effect when looking at them diagonally was
awful. They looked like square objects, no smoothing effect for the different
views. I would like to view objects from different angles and have different
views shown, but it seems that the current 3D engines out there always
present the same side no matter which way you are facing, so I'll try to get
that working first (hopefully). Thanks for the suggestion, we'll see what
happens.
Lary
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 368499
To: Lary Myers 76004,1574 (X)                  Date: 03-Jun-93  19:40:50

Yeah, that's a problem. If the object maps are oriented only along the same
axes as the wall segments, you lose the illusion of depth. I guess I'd lean
more toward treating them as sprites: use the same set of views drawn from
different angles, scale up or down as necessary, and blit them into the view.
There's still the clipping problem. I'm planning to take some time to look at
X3. I was very impressed with it, btw. You're really coming along. The
performance is vastly improved, and some of the objects turned out very well
(thinking of the trees in the corners).

                                                        --Mark
...........................................................................

Fm: Lary Myers 76004,1574                      # 368760
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 04-Jun-93  02:03:35

Mark, could you elaborate on your explanation? I see objects now as walls but
treated in such a manner that only the x or the y ray is used to determine
the bitmap column to display. I would like to scrap that all together and go
to placing the objects by an x,y coordinate then determining the distance and
bitmap column to display. What I'm having trouble with is the column based on
the angle between me and the object (ie the angle I spotted it at) and which
column of the bitmap to display which is based on several factors, one of
which is distance. I was thinking I could scale the width as well as height
based on distance, but.....

Thanks for the positive comment about X3. I'm pleased with the wall displays
(except for speeding up the actual display routines) and would very much like
to see objects that you can walk around which are moveable. That's my goal
anyway.
Lary
...........................................................................

Fm: TIM 76247,1130                             # 368942
To: Lary Myers 76004,1574 (X)                  Date: 04-Jun-93  12:19:44

  Lary,
  I've also looked at X3. Good work. I shudder at the thought of how
seriously brain-fried I'd get if I tried something so ambitious...
  That said, a couple of comments. (Well, you DID ask... <grin>) First, the
engine itself seems fairly solid. My experience with 3-D ranges from some
basic graphics work at school to spending rather large amounts of time with
the two Ultima Underworld programs and the Wolf program -- the Wing Commander
approach to objects may apply, too.
  Based on that experience, X3 demonstrates performance on my 486/33
comparable to that of either Underworld and WC2, and slower (by about 50%)
and jerkier than Wolf. That's not meant disparagingly; even that level is an
accomplishment. But from the perspective (sorry <g>) of your typical
non-programmer game player, X3 still suffers by comparison.
  Do you have a profiler? The wall raycasting seems pretty bullet-proof;
enough that it might make sense at this point to start looking for code to
optimize.
  Also, try this: approach a corner from 45 degrees, and stop. Now turn
right, then left, and watch the corner. Instead of seeing more of the
direction in which you're looking, it appears as though your feet are sliding
in that direction -- rather disconcerting.
  Second: objects. You're right; your handling of these needs more thought.
While, like Mark, I liked the LOOK of the bushes, there were a few places
where, if I positioned myself correctly, they appeared to jump about one
wall-width and go edge-on to the viewer. The sign object in the first room
displayed the same behavior.
  Otherwise, this looks really promising. Keep at it!
  -- Bart
...........................................................................

Fm: Lary Myers 76004,1574                      # 369096
To: TIM 76247,1130                             Date: 04-Jun-93  17:51:49

Bart/TIM - Thanks for the comments. Speed improvement is high on the priority
list. Will keep everyone posted as to its progress.

Lary
...........................................................................

Fm: David Szkilnyk 100026,1274                 # 368002
To: Lary Myers                                 Date: 02-Jun-93  22:48:15

    Lary -
      I've got some ideas running around in my head and I put forward
      them to my partner(girlfriend) and she loved it.

      I am sick of the normal vga stuff and I want to start supporting
      the vesa and xga modes.
      (Windows 'mmm I don't like this one)
      Many of the machines that I come in contact with are quite
      adequate to handle SVGA modes and speed.
      So why not give them the facilities to run games at the high
      modes. If the engine is design in such a fashion it shouldn't
      matter what mode you are displaying for. (upward and backward compat.)

      Viewing multi floors -
         OK, say scenario is a jungle evironment, the character could
         fall into a small pit and be able to view upwards into the
         trees, or along the floor of the jungle. I mean the scenarios
         are endless, I would get board of playing normal maze one
         viewing level all the time.

     David
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 368129
To: all                                        Date: 03-Jun-93  06:25:52

The following new files are now available in LIBRARY 11 (Game Design):

[76004,1574]
X3.ZIP/Bin       62681     02-Jun-93

  Title   : 3D Raycasting Engine, Beta Version 3 (IBM)
  Keywords: VGA GRAPHICS 3D RAYCASTING IBM

  This is the latest version of the current 3D engine. This file
  should supersede X1 and X2.ZIP if you have them. My thanks to all who
  have participated in this "adventure" so far and welcome to any who care
  to join in. This version has limited mouse and object support but enough
  to get the idea. VGA required.
...........................................................................

Fm: Lary Myers 76004,1574                      # 368321
To: Jaimi 71700,1202 (X)                       Date: 03-Jun-93  14:53:15

Jaimi - thanks for the comments on the 3D engine. Believe it or not, the way
you described doing transparent walls is already in the engine, just coded
for objects and not walls. Discussions on this end were already mentioning
walls with see through windows that would show walls behind them.
The source will become available soon. I was just explaining to Mark about
the thing becoming a hack that I wanted to clean-up before placing it in the
public eye. The original X1 source was more commented then the current stuff
is! I would like to get objects implemented as well before releasing it.
Lary
...........................................................................

Fm: Mark 'SAM' Baker 100025,444                # 368426
To: Lary Myers 76004,1574 (X)                  Date: 03-Jun-93  18:04:22

Lary,
        X3 runs pretty well on my 486sx, certainly with optimisation you'll
have a pretty good engine. With the graphics you've used, it looks very
Wolf-like.
        Are you planning on allowing objects that can be walked over/
through? Are you planning on giving a 'direction attribute' to objects;
allowing for different images being displayed depending on the direction the
player is looking at them from?

                                                Mark
...........................................................................

Fm: Lary Myers 76004,1574                      # 368476
To: Mark 'SAM' Baker 100025,444 (X)            Date: 03-Jun-93  19:19:29

Mark - Good to hear from you again. Yes, currently I am working on the scheme
to display moving objects, no luck yet - but... Showing different sides of an
object is something I would LIKE to do, whether it happens or not. I'm
looking more into texture mapping. If I can project a texture mapped object
over the walls then I might be on the right track.

Lary
...........................................................................

Fm: Vu Truong (Siliconis) 70242,3015           # 368415
To: Lary Myers 76004,1574 (X)                  Date: 03-Jun-93  17:41:22

Lary:

Your X3 looks awesome! Do you plan to release the source code to the general
public?


          -Vu
...........................................................................

Fm: Lary Myers 76004,1574                      # 368477
To: Vu Truong (Siliconis) 70242,3015 (X)       Date: 03-Jun-93  19:21:04

Vu - Yes I am. My original plan was put forth here in Game Design to release
the source and build a construction kit so that people who didn't want to
dabble in the source could still build 3D types of games. What do you think?

Lary
...........................................................................

Fm: Steve Salter 71732,3126                    # 368921
To: Lary Myers 76004,1574 (X)                  Date: 04-Jun-93  11:32:16

|Vu - Yes I am. My original plan was put forth here in Game Design to release
|the source and build a construction kit so that people who didn't want to
|dabble in the source could still build 3D types of games. What do you think?


Ooops, I should have read on a bit further. Both ideas sound good, Lary.

Steve
...........................................................................

Fm: Vu Truong (Siliconis) 70242,3015           # 369073
To: Lary Myers 76004,1574 (X)                  Date: 04-Jun-93  17:08:27

I think thats a great idea! I was asking because I didn't find any source to
X3. X3 looks GREAT!

     -Vu
...........................................................................

Fm: Lary Myers 76004,1574                      # 369094
To: Vu Truong (Siliconis) 70242,3015           Date: 04-Jun-93  17:50:03

Vu - X3 was an update over earlier versions. I am embarressed to place the
source up until I get it cleaned up. And I would really like to get objects
implemented fully as well (of course that probably leads to wanting to get
the next thing in and the next and ....) But I do plan on getting the stuff
into Game Design soon.

Lary
...........................................................................

Fm: Marc a Gaudet 70724,636                    # 368454
To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 03-Jun-93  18:48:12

Are there any good books, etc. pertaining to polygon-fill engines?

I do GIS work for a living, and i have some interesting data sources
available to me (Street centerline files, Parcel maps, building
footprints/elevations and digital orthophotos).

Has anyone considered using "real" data for their games (TIGER data maybe?)

I think a multi-player Tank shoot-em-up game in your own city would be kinda
cool.

Marc.
...........................................................................

Fm: Chris Lampton [GAMPUB] 76711,301           # 368687
To: Marc a Gaudet 70724,636 (X)                Date: 03-Jun-93  23:55:27

Er, well, the only book I know on polygon engines is my own, FLIGHTS OF
FANTASY. Somebody just uploaded a collection of Michael Abrash's columns to
LIB 11, under the name ABRDDJ.ZIP, I believe. That has a lot of good
information on programming polygons.

--Chris
...........................................................................

Fm: Frank Sachse 74140,2413                    # 368880
To: Lary Myers 76004,1574 (X)                  Date: 04-Jun-93  09:44:58

My compliments to the chef (and staff) for the fine work on X3!

With regards to movement it seems to be closer Ken's Labyrinth than Wolf, ie.
the degree of rotation per key stroke seems less than the the 10 degrees or
so in Wolf.

I have a couple of questions/suggestions...

1) Could such an engine be adapted to an "outdoor" setting, ie.
   fields & forests, not just indoors?  If so, how?  That would be
   my area of interest for the game I have in mind. 2) Would it be possible
it implement a way to pick up or take objects,
   either by walking over them (Wolf3D) or by pointing at them (UUW)? 3) Can
the speed be improved?  Optimized?  Using assembler for the
   important routines? 4) How can I modify the bitmaps or add to them?  What
art s/w would I
   need?  DP2e? 5) How can I start building my game using the engine, ie.
creating maps,
   levels, etc.?

- Frank, the ignorant but eager...

PS Paul Whittemore - FOF is available in quantity in World's Biggest
Bookstore and to a lesser extent in most Coles (about $50 cdn <sigh>)
David Szilnyk - I think the KD Software program your are looking for is
              "DC Games" by DC Software.  You can find the latest version &
                demos in Lib 9 (CRPG) of this Forum (browse: DCGAMES).
...........................................................................

Fm: Lary Myers 76004,1574                      # 369093
To: Frank Sachse 74140,2413                    Date: 04-Jun-93  17:48:03

Frank - Whew! Where to begin.

1) Already thinking of outdoor settings. If I get the &%&% objects to work
like I'm planning then its all set. Just picture the trees in X3 without
walls.

2) Picking up and dropping. Haven't addressed this yet. I'm leaning towards a
different interface then Wolf3D but haven't put one in concrete yet.

3) Currently working on speed improvement - watch for X4 soon!

4) The construction kit I'm planning will allow map and bitmap modification
as well as other items ala Breach.

5) How can you start? Don't know, not ready to put source up yet.....

Hope this answers some of the issues. X3 was meant as an update to show the
folks here in Game Design what progress had been made over the earlier X1 and
X2 samples. It is nowhere near polished or finished. Early responses like
yours are always welcome because I need to compile all the ideas and
incorporate them into the final construction kit.

Lary
...........................................................................

Fm: Mark 'SAM' Baker 100025,444                # 369771
To: Bart Stewart 76247,1130 (X)                Date: 05-Jun-93  18:39:03

You could do a lot with manipulating the palette: including generating an
'atmospheric haze effect; night and day; infravision and ultravision. I don't
know if Lary has his 'maximum visibility'  set up as a variable or a
constant; but perhaps he should include a call to his engine allowing this
too to be adjustable.

                                                Mark
...........................................................................

Fm: LAWRENCE M MATTA 70751,1424                # 371720
To: Lary Myers 76004,1574 (X)                  Date: 08-Jun-93  18:12:12

Lary-
I saw a preview of DOOM today, and it looks like the folks at ID have been
staying up late working on their engine.  It now has floors and cielings, and
the floor doesn't need to be flat.  Also, the walls can be at any angle, and
when you shoot, you leave permanent trails of bullet holes in the walls!
Looks like I've got a lot of work ahead of me...
Larry
...........................................................................

Fm: Frank Sachse 74140,2413                    # 378697
To:  76004,1574 (X)                            Date: 18-Jun-93  09:21:47

I'd like to respond to some of your questions from last night (at least the
few that I saw - if there are others please let me know)

How should you distribute your engine? - As shareware, ie. $20 for the engine
w/online docs but w/o source.
  $50 extra for the source.  That's how AGT does it.  And you (& those
  helping you) deserve it.  Everyone will want something for nothing,
  esp. a 3D engine.  And it's certainly cheaper than $25,000!

What would I use the 3D engine for? - I would use it as the basis for an RPG
game I am creating - the
  resulting product would then be distributed as shareware.

What would I do with the source code? - Add features to it.  The more that
already exist, the less I have to
  add.  Also, I am not that keen on advertising banners, since I want
  to make my game shareware.  You deserve credit & should be mentioned
  as the author of the engine, ie. 3Dengine Copyright 1993 Lary Myers -
  All rights reserved.  But I'm not fond of hard-coded banners like
  "You too can make 3D games like this one, using LM Inc.'s 3D-RPG
  Construction Set.  Call 1-800-555-1212.  Our operators are standing
  by.  Order before midnight tonight & we'll through in a fabulous
  Ginsu Assembler/Debugger..."

What can you contribute to the development of the engine? - generic sound,
bitmaps, map layouts & full screen graphics as they
  apply to the 3Dkit in general and not for a specific app since
  I have my own app in mind.  Also I know I am not as skilled in those
  depts as others here, but if no one else will do it, I will.

- Frank, the keen...
...........................................................................

Fm: Frank Sachse 74140,2413                    # 378697
To: Lary Myers                                 Date: 18-Jun-93  14:29:00

Before everyone puts me on their hit list, let me explain. I only suggested
shareware as a means to control subsequent versions of the engine.  If Lary
wants to give it away for free, that's fine by me.  But I know it would take
me forever to develop a 3D engine (given my current skill set) - so to me
that's worth something. Perhaps the amount should be more or less?  Perhaps
it should come with the source?

If Lary does most of the work, then it's only fair he be compensated somewhat
for his effort.  But if the finished product is more a combined effort of
many, then the shareware fee should either be eliminated or shared among the
contributors.

Perhaps make the fee optional, ie. what's it worth to you? There isn't too
much I could do with the engine right now, even if I had the source code
(except maybe add some sound stuff).  But I'd be willing to cough up a few
sheckles if it came with a map/object/room/ NPC editor, sound, scripting,
etc.

I'd be interested in a con transcript if & when it becomes available, since I
missed most of it.

- Frank
...........................................................................

Fm: Lary Myers 76004,1574                      # 378744
To: Frank Sachse 74140,2413                    Date: 18-Jun-93  15:52:16

No Frank, I don't think you're on anybody's hit list. It seems the general
concensus was to make the engine Freeware for private use and have a licence
agreement or some such for commercial use. That seems fair to me, after all,
my original goal was to place the technique for ray casting into the general
public so others could share in the visual effects and produce thier own
games and applications. What people around me continue to beat on me about is
that shouldn't there be some tighter control on someone using the engine to
make a commercial game, raking in lots of money, and me not seeing a dime? I
don't know, maybe if more game techniques became available to everyone then
we could get out of the rut we're in with games all being the same.... I have
to think about this somemore....

Comments are welcome - Lary
...........................................................................

Fm: Jaimi the OverTaxed 71700,1202             # 378964
To: Lary Myers 76004,1574                      Date: 18-Jun-93  21:43:11

Lary, I hope you consider everything when or if you come to a decision on
licensing your engine. In come cases an engine can be a good portion of the
game (especially in arcade games), but in many (if not most) cases, the
engine is a relatively minor part of game development. Graphics, sound,
story, plot, etc usually occupy the lions share of development time. How many
times have you looked at software, and decided against it because they
charged royalties or a fee if you used it in a product. Many people would not
bother to even use it for personal use if they had the spectre of a fee if
they went commercial hanging over their heads. Instead, If you truly wish to
see some money from it, I say charge it in advance. The people will know in
advance how much it would be, and would then be able to develop with
impunity. However, I think that the most profit could come, like you say, of
it just being freeware. You could build a good name for yourself in the
industry, and in the end, more and better software could be developed. Who
knows? Maybe some of those poor college students out there (who could not yet
afford to license something like this) or someone else of similar nature,
will come forward with enhanced code, or floor tiles, or multi-level floors,
or some hitherto unthought of feature? It could get on the internet, and the
whole world could help improve it.

Jaimi
...........................................................................

Fm: Lary Myers 76004,1574                      # 379043
To: Nelson Yu 72066,1744 (X)                   Date: 19-Jun-93  00:23:05

Nelson, thanks for the comments. No, it shouldn't be any slower based on a
coprocessor, however, I just recently had the chance to see it on a friends
machine with a different VGA card. It was SLOW!!! I need to concentrate on
this area before it really becomes a contender with the other 3D engines out
there.

Lary
...........................................................................

Fm: Nelson Yu 72066,1744                       # 379090
To: Lary Myers 76004,1574 (X)                  Date: 19-Jun-93  02:54:17

>Nelson, thanks for the comments. No, it shouldn't be any slower based on a
>coprocessor, however, I just recently had the chance to see it on a friends
>machine with a different VGA card. It was SLOW!!! I need to concentrate on
>this area before it really becomes a contender with the other 3D engines out
>there.

I'm not sure how you could "speed up" the VGA card other than having your
friend go out and buy another.

One sure fire way to speed up X3 is to redo it entirely in assembly language.
...........................................................................

Fm: Jerry Isdale 72330,770                     # 379511
To: Lary Myers 76004,1574 (X)                  Date: 19-Jun-93  22:07:16

Lary,
 Posting the binary libs and some example programs would be one good way to
distribute it, if you want to be shareware. The paying customers could get
source and better documentation.

 I've come in late on this 3D engine bit. I've been working with the Rend386
stuff, which isnt nearly the same as much of what you folks are talking
about. However, there is a great interest in both styles. (Rend386, and the
whole of the VR stuff has moved from the GraphDev forum to the new
CyberForum.)

Jerry Isdale
...........................................................................

Fm: Lary Myers 76004,1574                      # 379541
To: Jerry Isdale 72330,770                     Date: 19-Jun-93  23:16:21

Thanks Jerry, seems to be a common point of view. I would guess that the
folks who want to dig into the technique, perhaps modify or rewrite it, vote
for source as well as executable, while those who want to see what kinds of
games/apps can be written, really want a construction kit. I am still
considering the matter.
Lary
...........................................................................

Fm: Lary Myers 76004,1574                      # 379044
To: Jaimi the OverTaxed 71700,1202 (X)         Date: 19-Jun-93  00:26:34

Very good points Jaimi, and I am still pondering over the issue as yet. I am
finding, as you say, that as more is added to the construction kit, that the
ray casting routines themselves are becoming a smaller and smaller part of
the overall project. And, I haven't looked at EMS/XMS, or sound, or a dozen
other details. Thank you for the words of wisdom and I will factor it all
into my final decision.

Lary :)
...........................................................................

Fm: Bart Stewart 76247,1130                    # 379078
To: Lary Myers 76004,1574 (X)                  Date: 19-Jun-93  01:47:31

  And here's a view from the cynical side of the street: why not take your
3-D algorithm, find a way to do it in hardware, and patent it?
  If that's not to your liking <g>, here's another point of view. I've found
that most of the best (and clearest) programs I've written have been those
which were written -- from scratch -- twice. The first one is sort of a
proof-of-concept; the second version, when I know what I want and how to
accomplish it, is invariably easier to read, maintain, and enhance.
  In the world of work, managers are rarely willing to permit you to make
that second pass, much less encourage you. But since this isn't "work," per
se, you have the opportunity to take as much or as little time as you like on
this project. With that in mind, one way to look at this project is that the
current version is a proof-of-concept, which all of us can learn from. Once
it's clear what kind of things work (or don't work), you can write the "real"
3D engine, and distribute/license/sell it any way you like.
  Comments, anyone?
  -- Bart
...........................................................................

Fm: Andrew Amess 100141,1567                   # 379171
To: Bart Stewart 76247,1130 (X)                Date: 19-Jun-93  09:34:14

I agree with most of the points here. But what you all seem to be missing,
and this may just be something I suffer from, is:
Who can read and understand somebody else's code anyway!? I think what may be
valuable is a detailed document on the theory, cut out the jargon because I
know zilch about maths, but I do know C C++ and ASM so I don't need to
struggle against somebody else's style of doiung things. What I need
personally is someone who has done a lot of thinking about an area and pay
them for the explanation. That way you own personal engine is developed for
your own project and is not based on some generic blob (don't take that as an
observation on the program under discussion coz I am wetting my pants just
thinking about running it!) But anyway you probably get my point. Most of us
here could write engines all day long, I have just done one with a friend for
platform games that has two demos with 9 or 10 levels of 'busy' parallax. But
there is no way on God's earth I could learn about this ray casting business
by tea time, eh?! So there's my point of view and to put it in a nutshell,
why not write a book for heaven's sake and put the ting \on a disk inside the
cover. 35.00 quids is not a lot for the benefits to be had. Hope this is
constructive.
...........................................................................
Fm: Lary Myers 76004,1574                      # 379268
To: Bart Stewart 76247,1130 (X)                Date: 19-Jun-93  13:28:47

Good points Bart, and being both an engineer and a manager at work I know
exactly what you mean about that second pass. I think I'm leaning back
towards putting the doggone thing up "as is" (I do have a rather lengthy
albiet dry documentation file which descibes ray casting) and letting people
run with it. What the hey, if it gets used for the benefit of all, then so be
it! (Sounds pretty noble eh?). My thoughts are that, even though mega-hours
have been put into the thing, I probably would have put those hours in anyway
because I wanted to see if I can do it. Not how complete, or how fast, or
what-have-you, just "Could I do it?" I've answered that question and now have
to struggle with - "Now that I have it, what am I going to do with it".
Writing it a second time is very appealing and I may just take that approach
(Don't worry all, I'll upload what I have first!).
Thanks for the comments.
Lary

___________________________ Subj: ACK3D Release ___________________________

Fm: Lary Myers 76004,1574                      # 380275
To: All                                        Date: 20-Jun-93  22:32:30

I just uploaded the following files to Game Design; ACKSRC.ZIP which is the
full source, header files, etc and ACKKIT.ZIP which is the Construction Kit
in its present, uncompleted form. I decided to uploaded the stuff "as-is"
because of pressing deadlines at work, which will keep me from spending time
with the engine, and I know many of you are anxious to begin using it for
your own creations. Please accept my apologies for the incompleteness of the
files, I simply ran out of time, and for any gross errors that you may find
in the code.
After considerable thought on how to distribute the engine, I've settled on
giving it to the general public as PULICWARE, please see the text files
included in the above mentioned ZIP files for further details.
My thanks to all of you how have provided support and encouraged me to work
steadily on the engine, I had some hair raising moments where I wanted to
toss the whole thing out the nearest window, if not for your quick and
concerned comments, I might have done just that.
This will probably be the only version of the source that I upload. Now that
its out , I will continue on my own path with other goals I have for the
engine. I've already used it at home to build mazes that my kids love to walk
through, giving me much satisfaction, and I have other ideas I'd like to try
out. But I didn't want to keep everyone waiting, so here it is!

Thanks again,
Lary Myers
...........................................................................

Fm: John W. Ratcliff 70253,3237                # 381153
To: Lary Myers 76004,1574 (X)                  Date: 21-Jun-93  23:30:26

Larry,

It's called a royalty.  I think that would make all happy.  Technogogy fades
fast, so get it out there, make some friends, and share in the profits.

John.
...........................................................................

Fm: Lary Myers 76004,1574                      # 381168
To: John W. Ratcliff 70253,3237 (X)            Date: 22-Jun-93  00:08:04

Thanks John - I've already uploaded the entire kit-and-kaboodle as freeware.
That was my intention from the start, to share the technique with everyone.
It's nowhere near finished, or even commercial quality (not just my opinion)
so its left up to those out there to see what can be done with it. I will be
continuing on the construction kit for those who don't want to get into the
engine, and I've already added things to the engine that have not been
uploaded.....We'll see. Thanks for the comments.

Lary
...........................................................................

Fm: John W. Ratcliff 70253,3237                # 381397
To: Lary Myers 76004,1574 (X)                  Date: 22-Jun-93  09:47:04

Lary,

If I can find the time, I will re-write the 2d primatives and re-upload that
as free-ware.  A rewrite of the 2d should help the frame rate.  It's still in
mode-X right?  Moving it out of mode-X will speed it up on most graphics
cards.

John.
...........................................................................

Fm: Lary Myers 76004,1574                      # 381433
To: John W. Ratcliff 70253,3237 (X)            Date: 22-Jun-93  10:56:24

Thanks John, I look forward in seeing what can be done with it. When you
download the source you will find some ASM files that allow the engine to
work in a variety of modes. It is in a mode X mode now, there are also
version in straight mode 13h as well.

Lary
...........................................................................

Fm: Jaimi the OverTaxed 71700,1202             # 380587
To: Lary Myers 76004,1574 (X)                  Date: 21-Jun-93  11:15:50

Thanks Lary! You're a hero! Now if it will only becaome available for
download!

Jaimi
...........................................................................

Fm: Lary Myers 76004,1574                      # 380641
To: Jaimi the OverTaxed 71700,1202 (X)         Date: 21-Jun-93  12:16:52

Thanks Jaimi - "Hero"?? HA! You haven't seen the code yet!!!! <G>

Lary
...........................................................................

Fm: Nelson Yu 72066,1744                       # 380655
To: Jaimi the OverTaxed 71700,1202 (X)         Date: 21-Jun-93  12:40:44

>Thanks Lary! You're a hero! Now if it will only becaome available for
>download!

Me too, I'm always trying to download a file that's not there.
...........................................................................

Fm: Bart Stewart 76247,1130                    # 380625
To: Lary Myers 76004,1574 (X)                  Date: 21-Jun-93  11:59:39

  Thanks, Lary. I'm looking forward to seeing "NEW IN GAMDEV LIB!" too. <g>
Just want to let you know that if anything I do with your code sees the light
of day, you'll get full credit.
  Say -- does that mean we can include your phone number for support? <grin>
  <kidding> Thanks again for being willing to share your hard work, Lary.
  -- Bart
...........................................................................

Fm: Lary Myers 76004,1574                      # 380642
To: Bart Stewart 76247,1130 (X)                Date: 21-Jun-93  12:17:53

Thank you Bart. There is still so much I wanted to do with it. I hope people
don't look at what's there and get disappointed when its not complete.

Lary
...........................................................................

Fm: Patrick Reilly 71333,2764                  # 380771
To: Lary Myers 76004,1574 (X)                  Date: 21-Jun-93  15:01:40

Lary,
  I'll send you a copy when I get it encapsulated in C++... <G>
  Thanks - look forward to checking it out... (maybe some grateful artist
types will create some nice panels for your kids' games...)
        -Pat-
...........................................................................

Fm: Lary Myers 76004,1574                      # 380791
To: Patrick Reilly 71333,2764 (X)              Date: 21-Jun-93  15:31:58

Thanks Pat - Yes, that would be nice to get a variety of bitmaps. Maybe we
could start a library of bitmaps right here in Game Design?
Looking forward to seeing the C++ equivalent....

Lary
...........................................................................

Fm: Patrick Reilly 71333,2764                  # 380880
To: Lary Myers 76004,1574 (X)                  Date: 21-Jun-93  18:12:35

Lary,
  From all the people (myself included <g>) that have been pestering you
about the engine, there should certainly be enough interest/usage that a lib
of panels would not be tiny...
        -Pat-
...........................................................................

Fm: Lary Myers 76004,1574                      # 381038
To: Patrick Reilly 71333,2764 (X)              Date: 21-Jun-93  21:26:25

Great! Maybe I should look at a conversion utility to write the raw image
files or something similiar. In its present form the engine will read raw
images or Deluxe Paint BBM files. The first thing would be a modification to
read from a single picture file instead of all the separate little files.....
Uhmmm....

Lary
...........................................................................

Fm: Patrick Reilly 71333,2764                  # 381248
To: Lary Myers 76004,1574 (X)                  Date: 22-Jun-93  02:15:11

Lary,
  Though I only use Windows once in a proverbial blue moon, a *lot* of people
do (and nearly everybody *can*) - which means that Windows' .BMP files might
be of interest (the MSC and BC++ manuals explain the file format and, for
BC++, the Resource Workshop can create .BMP bitmaps...) Of course, you'd need
to run Windows in a 256-color mode to make the *right* ones...
        -Pat-
...........................................................................

Fm: Lary Myers 76004,1574                      # 381434
To: Patrick Reilly 71333,2764 (X)              Date: 22-Jun-93  10:57:49

That would be the problem for most Pat, since a SVGA card would be needed to
get the 256 colors out of Windows. I have access to a variety of cards, but
normally only use Windows in 16 color mode.

Lary
...........................................................................

Fm: Nelson Yu 72066,1744                       # 381494
To: Patrick Reilly 71333,2764 (X)              Date: 22-Jun-93  12:54:25

>Though I only use Windows once in a proverbial blue moon, a *lot* of people
>do (and nearly everybody *can*) - which means that Windows' .BMP files might
>be of interest (the MSC and BC++ manuals explain the file format and, for
>BC++, the Resource Workshop can create .BMP bitmaps...) Of course, you'd
need >to run Windows in a 256-color mode to make the *right* ones...

It a hassle to work with Windows in 256-color mode. First problem is finding
drivers, second would be, only bitmaps are in 256-colors, everything else no
matter what, it's usually in 16-colors. 8(

It's a honeymoon at first, but you find CPU and the video card have better
things to do<g>.
...........................................................................

Fm: Patrick Reilly 71333,2764                  # 381653
To: Nelson Yu 72066,1744 (X)                   Date: 22-Jun-93  17:08:27

Nelson,
  What I was thinking (and might try this for REHACK) is to just load a
256-color driver for *making* bitmaps, then swap back to my 16-color for
normal Windows work (which is basically non-existent except for the Recorder
to make WAV files)...
        -Pat-
...........................................................................

Fm: Nelson Yu 72066,1744                       # 381754
To: Patrick Reilly 71333,2764 (X)              Date: 22-Jun-93  19:27:44

>  What I was thinking (and might try this for REHACK) is to just load a
>256-color driver for *making* bitmaps, then swap back to my 16-color for

I guess you'll strip the header off the Windows bitmap? and to make sure
there is no RLE..

>normal Windows work (which is basically non-existent except for the Recorder
>to make WAV files)...

Can't say I love it, can't say I hate it. I just use it<g>.
...........................................................................


Fm: E. Pinnell [CyberSim] 70031,435            # 382215
To: Nelson Yu 72066,1744 (X)                   Date: 23-Jun-93  10:15:03

Nelson,

  Programming Windows to do anything useful is a major PITA.  OS/2's APIs are
*MUCH* nicer.  Unfortunately, MS marketing whips IBMs marketing, so we're
stuck with Windows.

Eric Pinnell;
...........................................................................

Fm: Nelson Yu 72066,1744                       # 382574
To: E. Pinnell [CyberSim] 70031,435 (X)        Date: 23-Jun-93  20:22:01

>  Programming Windows to do anything useful is a major PITA.  OS/2's APIs
are >*MUCH* nicer.  Unfortunately, MS marketing whips IBMs marketing, so
we're >stuck with Windows.

Your the last one to tell me OS/2 APIs are better than Windows'(no offence).
I know it! But the fact the major problems with Windows 3.x are
fixed/covered up/still there?<g> in Win32. I dislike MDI and prefer OS/2's
Parent->Child relationship.

P.S As long as you hide the problems and for me NOT to use the C/SDK, who
wouldn't be happy?
...........................................................................

Fm: E. Pinnell [CyberSim] 70031,435            # 382906
To: Nelson Yu 72066,1744 (X)                   Date: 24-Jun-93  09:00:48

Nelson,

   Win32 is a heck of a lot better than Win16.  However,  NTs market share
isn't going to amount ot a row of beans. Some people are trying to use Win32s
on top of Win 3.1 so they can port easy to NT, but the reality is, to design
a threaded program means reengineering that program from the ground up.  And
despite what the press pundits say, Windows 4.0 won't be around until early
1995.    Personally, I am going to write my code to make it portable.  It's
the only  way to go in the 1990's.

Eric Pinnell
...........................................................................

Fm: Nelson Yu 72066,1744                       # 382933
To: E. Pinnell [CyberSim] 70031,435 (X)        Date: 24-Jun-93  10:02:21

>   Win32 is a heck of a lot better than Win16.  However,  NTs market share
>isn't going to amount ot a row of beans.

True, but I don't think MS intended it to take the lion's share of the
market.

>Some people are trying to use Win32s on top of Win 3.1 so they can port
>easy to NT,

I guess Microsoft isn't the one encouraging that or are they? Well one
reason they might is, OS/2 can not even possibly run Win32s programs(VxDs).

>but the reality is, to design a threaded program means reengineering that
>program from the ground up.

What's life without multi-threading and asynchronous i/o?
An app can achieve maximum performance by taking advantage of threads.
So it's worth the extra effort...sometimes, unless it's very small.

>And despite what the press pundits say, Windows 4.0 won't be around until
>early 1995.

Write for Win32 and port to Win32c then...

>   Personally, I am going to write my code to make it portable.  It's the
only > way to go in the 1990's.

With C++, App. Frameworks? Class libs? Tool X? The fact portability libs
are lowest common denominator of all the OSes they support. They take no
advantage of the OS capabilities(i.e No lib has threading available).

How else are supposed to make your code portable? You surely wouldn't use
any "advanced features" or maybe encapsulate the threading process, the
initialization process etc.. It hard to make your code portable when
everyone has their own ideas on what's "standard". One thing I know, avoid
writing C code like the plague, C for GUIs is as non-portable as you can
get.
...........................................................................

Fm: E. Pinnell [CyberSim] 70031,435            # 383273
To: Nelson Yu 72066,1744 (X)                   Date: 24-Jun-93  19:30:12

Nelson,

    Actually, IBM plans to add VxD support for the next version of OS/2.  As
MS says, it's simply a matter of 1's and 0's.  Encalsuplation can help a lot,
and this is what I intend to do.  The GUI stuff is portable, albeit at a very
simple level. I prefer to use C++.

Eric Pinnell
...........................................................................

Fm: Nelson Yu 72066,1744                       # 383370
To: E. Pinnell [CyberSim] 70031,435            Date: 24-Jun-93  21:43:40

>    Actually, IBM plans to add VxD support for the next version of OS/2.  As
>MS says, it's simply a matter of 1's and 0's.

What I expected, but can they? MS has a lot of trickery, not all of which
do I find funny. 'Though having Win32s compatability is another story.

>Encalsuplation can help a lot, and this is what I intend to do.  The GUI
>stuff is portable, albeit at a very simple level. I prefer to use C++.

GUI program designs are... code isn't(not a problem unless the app has more
than 10 000 lines of code).

IMHO, a Win32 <-> OS/2 port is still considerably difficult(if you were to
try it), let alone one from DOS(wouldn't try it!). Encapsulating OS/2's GPI,
WIN, 'DOS' APIs and Win32's GDI and the other totally disorganized and
pathetically named, yet very functional<g> APIs is a herculean task.

The only way possible is with a 3rd party tool/lib or you design your own
App. Framework with all the 'goodies' of each OS. Either way it's easier to
simply write plain vanilla OS/2 PM or Win32 C++ code.

P.S I'll never understand IBM's pricing scheme.. C Set++, OS/2 2.1 and
C Set/2 are all oddly priced.
...........................................................................

_________________________ Subj: Applause for ACK3D! _________________________

Fm: Mark Betz/Ass't SysOp 76605,2346           # 381920
To: Lary Myers 76004,1574 (X)                  Date: 22-Jun-93  22:12:45

Hi, Lary. Just wanted to be the first to give you a round of applause for
ACK3D.

<clap, clap, roar, shout, bravo!>

I think you deserve a major pat on the back, not just for what you've
accomplished with the engine, but for your decision to release it to the
public domain. That's in the true spirit of this place, and I was very happy
to see it work out that way.

The engine is overall much faster and smoother. The doors and objects are
very nice. I'm still figuring out the map editor, and I think someone needs
to write a good wall and object editor for it (isn't someone working on
that?)

All in all a major accomplishment!
                                                        --Mark
...........................................................................

Fm: M&S Harrison (DES) 76057,101               # 381956
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 22-Jun-93  22:41:39

Mark,

 It sounds like you've seen what he uploaded...

 If so, when will it be available in the libs?
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 382102
To: M&S Harrison (DES) 76057,101 (X)           Date: 23-Jun-93  06:42:11

Hi, Michael. The two files ACKSRC.ZIP and ACKKIT.ZIP, should be available in
LIBRARY 11 (Game Design) now.
                                                        --Mark
...........................................................................

Fm: Lary Myers 76004,1574                      # 381969
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 22-Jun-93  23:11:28

Mark,
  Thank you very much for the comments. It's just that sort of feedback that
make all the work seem worth it. While the entire project was not anywhere
near finished my thought was to put things up "as-is" to allow others to
expand on what had already been done. It will now be up to everyone to decide
if they wish to contribute to the lib with thier own enhancements. Maybe the
Game Design lib will be a good place for people to visit, get involved with
some code, design some games, and so forth. With Bob's ReHack project
starting up nicely, and ACK3D as well, things are looking mighty exciting in
this library. I'd also like to thank you Mark, because I know what being a
SysOp means as far as time and effort. Keep up the good work!
Lary
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 382103
To: Lary Myers 76004,1574 (X)                  Date: 23-Jun-93  06:42:13

Thanks, Lary. I think this section was intended to be exactly what you
describe, and over the years it's certainly turning out that way.

                                                        --Mark
...........................................................................

Fm: M&S Harrison (DES) 76057,101               # 381995
To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 22-Jun-93  23:51:48

Mark,

 I hope my last message didn't come across as harsh... That's not how it was
meant.  I'm just eager to see ACK3D to see how difficult it would be to
include in ReHack.

 - MichaelH
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 382104
To: M&S Harrison (DES) 76057,101 (X)           Date: 23-Jun-93  06:42:16

Nope, not harsh at all. Standard "where the hell is the file" request. Get
'em all the time <g>.

                                                        --Mark
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 382097
To: all                                        Date: 23-Jun-93  06:28:14

The following new files are now available in LIBRARY 11 (Game Design):

[76004,1574]
ACKSRC.ZIP/Bin     146411     20-Jun-93

  Title   : ACK-3D Engine Source, Beta Version (IBM)
  Keywords: ACK 3D GRAPHICS VGA RAYCAST SOURCE CODE IBM

  Here is the source code and associated files for the ACK3D engine.
  This version uses Borland C++ Version 3.1 and Microsoft MASM assembler. To
  run the engine with bitmaps and map files please download the file
  ACKKIT.ZIP also available in this library. Uploaded as PUBLICWARE by the
  author. Replaces last iteration in X3.ZIP (Library 11).


[76004,1574]
ACKKIT.ZIP/Bin     152535     20-Jun-93

  Title   : ACK-3d Construction Kit, Alpha Version (IBM)
  Keywords: ACK 3D GRAPHICS VGA RAYCAST SOURCE CODE IBM

  This is the runtime construction kit (not fully completed yet, but
  usable) for the ACK3D engine. The source for the engine is contained in the
  file ACKSRC.ZIP also available in this library. A VGA is required. Uploaded
  as PUBLICWARE by the author.
...........................................................................

Fm: John Roberts 72677,3265                    # 382390
To: [F] SYSOP (X)                              Date: 23-Jun-93  15:53:13

Hi,

I've been following the Game Design messages and hear talk of two files
recently posted, ACKSRC.ZIP and ACKKIT.ZIP (posted by Lary Myers -- 76004,
1574).  I can't seem to find them in the library.

Can you help?

thanks,

John
...........................................................................

Fm: Nightshift/SYSOP 76703,657                 # 382394
To: John Roberts 72677,3265 (X)                Date: 23-Jun-93  16:07:43

Hi John -- The files are available in our Library 11 (Game Design).  Which
command did you use when looking for them?  BROWSE will retrieve them.

     * Nightie *
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 382516
To: John Roberts 72677,3265 (X)                Date: 23-Jun-93  19:30:45

Hi, John. As Nightie has pointed out, those two files are available in
LIBRARY 11 (Game Design). In LIB 11 you can type BRO KEY:ACK to find the
files, or if you happen to be in a different library, type BRO ALL KEY:etc.
to find files across all of the libraries. See the help files in LIBRARY 1
(General/Help) for more information, or type HELP at any ! prompt.

                                                        --Mark
...........................................................................

Fm: Bob Provencher/GD SL 71621,2632            # 382581
To: John Roberts 72677,3265 (X)                Date: 23-Jun-93  20:30:49

Hi John,

As Nightie's already told you, the files are available in Library 11.  I;ve
just checked and they are there, do you need help downloading them?

Bob
...........................................................................

__________________________ Subj: Future of ACK3D __________________________

Fm: Frank Sachse 74140,2413                    # 382954
To:  76004,1574 (X)                            Date: 24-Jun-93  10:39:02

Thanks Lary for making your engine & source available.  I would like to
return the favour by adding to it what I can, and perhaps others can do the
same, so that we can collectivity make improvements.  I'm not sure what Lary
had in mind from here on, ie. what future mods he has in the works, but here
is a summary things that needs to be added or improved (from NOTES.txt in
ACKSRC.zip):

a. Accuracy at certain angles
b. Objects are getting clipped off the screen when their centerpoint is
   reached.
c. Collision detection
d. Secret doors are mariginally working.
e. Object movement is restricted to always turning right when bumping into an
   obstacle.
f. Other types of doors, besides secret and sliding doors needs to be
   implemented.
g. The goal actions need to be enhanced

I would add to that sound capabilities, ie. CMF/VOC/MID/MOD/etc.  I can't
help much on A-G above, but I will work on the sound part, if that helps,
then turn my mods over to Lary for inclusion in future releases of the
engine.  Is that how we should preceed now?  Make our own mods and make them
available to others here or only thru Lary?

Perhaps those more artistically inclined can create more objects & walls?

Just trying to keep the ACK3D ball rolling.

- Frank, self-appointed ACK3D ball roller...
...........................................................................

Fm: Frank Sachse 74140,2413                    # 383050
To: Lary Myers 76004,1574 (X)                  Date: 24-Jun-93  12:46:36

I forgot to add to the wish list:

- moving objects - people (moving & stationary) - interacting with objects,
ie. picking up -> invoking action, like a sound
  or message

Is someone working on these or how should I go about doing it myself?
Thanks...

- Frank

PS does someone have a relatively complete con transcript from last Thurs? If
so, please email me one.  Thx!
...........................................................................

Fm: Lary Myers 76004,1574                      # 383096
To: Frank Sachse 74140,2413 (X)                Date: 24-Jun-93  13:57:49

Hi Frank, Sounds like a good idea to keep the ball rolling. I would hate to
see the whole discussion die out now that everyone has access to the source.
Here is one suggestion:

I am willing to mediate release of future versions if nobody has any
objections, so if anyone has new features or modifications, or suggestions,
then upload them to me and I will put together a release upload. This would
avoid having mulitple versions in the lib and the confusion on which one to
download. In fact, my copy of the engine is already significantly different
from the uploaded version that I had to write a map conversion utility to
convert my old maps to the new format. This one change alone would make it
difficult to know which engine to use and so forth. Let me put out a message
to all and see what the response is...
Lary
...........................................................................

Fm: Lary Myers 76004,1574                      # 383471
To: Frank Sachse 74140,2413                    Date: 24-Jun-93  23:37:22

Hi Frank,

>>PS does someone have a relatively complete con transcript from last Thurs?
If so, please email me one.  Thx!

Yep! I uploaded a transcript just today so it should be appearing soon.

Lary
...........................................................................

Fm: Lary Myers 76004,1574                      # 383101
To: All                                        Date: 24-Jun-93  14:03:45

Now that ACK3D has been released and is getting into the hands of quite a few
of you, we should consider where to go next. One of the areas to concentrate
on is how to maintain source control (I know, an ugly term, but
necessary...). I am willing to mediate changes/enhancements, etc into the
engine and build a version for future releases. This accomplishes two goals.
One, it allows all changes to be funnelled through one source, and two, it
lets me see what impact the changes will have on the overall project. If
nobody has any objections then we can proceed on this. When you have an
update and wish to contribute it to the overall library then upload it to me
via my email address and I will merge it into the engine. I already have a
different version of the engine than what was uploaded and continue to work
on it steadily (time permitting). Let me know how you all feel about this
approach or any suggestions on how to proceed.
Lary
...........................................................................

Fm: Lary Myers 76004,1574                      # 383104
To: All                                        Date: 24-Jun-93  14:07:56

Just wanted to let everyone know what's been happening since the source and
kit were uploaded:

1. Major changes have been made to the way maps are stored internally in
ACK3D. They now take up a word instead of a byte and there is now a separate
map for objects and walls.
2. There are now three types of doors. Normal sliding doors, splitting doors
(ala Star Trek) and the secret doors.
3. Basic sound blaster support has been added to the goal screen where it
will play a .VOC file when displaying the final goal screen. (This was a
temporary add-in to thrill the kids, and is planned to be greatly enhanced).
4. Changes to the map editor to correspond to items 1 and 2 above.
Lary
...........................................................................

Fm: Lary Myers 76004,1574                      # 383111
To: All                                        Date: 24-Jun-93  14:18:14

Here is a breakdown of some suggestions for what can be started and
contributed to for the ACK3D project:

1. Bitmaps! The more bitmaps we can get the better. Any and all themes can be
addressed, space, fantasy, etc. The bitmaps can take the form of raw image
files or Deluxe Paint II .LBM or .BBM files. Hopefully a library can be
started in the Game Design lib where you can log in, select the theme you are
interested in, and download....
2. Sound - I've already got some interested parties looking into this, the
basic requirement is what the theme will be to create the sound. This cannot
proceed too far until sound support is built into the engine, but we should
be thinking about a sound library.
3. Coding changes - Areas such as performance, the ability to shoot,
interaction with objects, etc. These are all areas that someone can take the
ball and run with it. Any and all contributions will be welcome.
4. Utilities - Map editors, image editors, etc. are all areas that can be
concentrated on.

Bottom line: LOTS of things to do! This can be a very exciting and fun
project if we all pool are respective talents and donate what we have to a
common goal. I don't mean give away everything, just what you feel will help
and what you're comfortable with. I am willing to mediate all changes to the
engine unless someone else wishes to coordinate building uploadable releases.
Let me know and please let me know of any comments/suggestions on anything
concerning the project.

Thanks, Lary
...........................................................................

Fm: Lary Myers 76004,1574                      # 383120
To: All                                        Date: 24-Jun-93  14:32:04

Okay, how about a show of hands on who wants to work on the following:

1. Bitmaps (the 64x64 images used for walls and objects)
2. Full screen displays (320x200 256c pictures for still areas like the goal
and storyline).
3. Sound (various sounds including walking, doors creaking and swooshing,
etc)
4. Video enhancements (SPEED - FASTER and FASTER!)
5. Object intelligence (Objects that move towards you, away from you, etc)
6. Utilities (Map Editors, Object/Image editors, etc)
7. Game Ideas (We need a selection of storylines to begin working towards).

Let me know if you would like to contribute to any of the areas above, or any
other areas you feel comfortable with. I will maintain a list and post
progress reports periodically so we can all get a feel of how things are
coming along.

Thanks - Lary
...........................................................................

Fm: Bart Stewart 76247,1130                    # 383148
To: Lary Myers 76004,1574 (X)                  Date: 24-Jun-93  15:50:24

  Lary, it seems to me, after running/examining the latest incarnation of
ACK3D, that there's still a lot of work to be done in two areas before it
will make sense to really think about scenario design.
  First, the engine itself seems to be running at Wolf speeds now -- well
done! But it's no insult when I say that the player/world interaction -- the
object handling -- is still extremely primitive. For example, will you want
the player to be able to manipulate objects, or limit yourself to the Wolf
model, where moving onto object squares simply updates a status? If you want
to interact with the world, that implies a user interface; mouse cursors,
keyboard controls, and so on. Also, what you DO with any object has to be
displayed somehow. How will you show laser blasts or fireball spells?
  Secondly, a working, complete game will need a sort of "shell" built as an
interface between the graphics engine and the player. This layer would be
where you keep track of (and display) things like health, current weapon,
objects in your possession, and so on. I can see there being a lot of variety
in what people want to show the user, so I'm not sure it makes sense to
expect YOU to build this. I bring it up because it may affect the engine
itself.   Displaying a Wolf-style status bar at the bottom of the screen is,
I would think, nearly essential, and means that you no longer have to display
as many rows of maze display data. Displaying an Underworld-style menu/item
area on the right of the maze display means fewer columns to calculate and
display. Let me suggest this: let those who want to work out their own
presentation layer. For your part, you could make that a lot easier by
generalizing your display engine to programmer- (or even user-) definable
scales. That is, retool the display part to make variables like XWinSize and
YWinSize out of 320 and 200, respectively.
  Comments?
  -- Bart
...........................................................................

Fm: Patrick Reilly 71333,2764                  # 383227
To: Bart Stewart 76247,1130 (X)                Date: 24-Jun-93  18:19:24

Bart,
  One thing you might want to keep in mind is that some of the REHACK work
will probably be applicable toward your interface stuff; the windows classes
(including a framework, event messaging, buttons, etc) But they WOULD require
that the 3D area be non-full-screen...
        -Pat-
...........................................................................

Fm: Bart Stewart 76247,1130                    # 383493
To: Patrick Reilly 71333,2764                  Date: 25-Jun-93  00:07:19

  Pat, using Rehack classes as part of ACK3D code would require that the
Rehack code be converted from C++ to straight C. Are you volunteering? <g>
...........................................................................

Fm: M&S Harrison (DES) 76057,101               # 383600
To: Bart Stewart 76247,1130                    Date: 25-Jun-93  06:09:15

Bart,

 >> Pat, using Rehack classes as part of ACK3D code would require that the
Rehack code be converted from C++ to straight C. Are you volunteering? <g>

 Actually, you could port ACK3D to C++ just as easily.  In either direction,
it's not very hard.  <no, I'm not volunteering :-) maybe someday when I have
gobs of free time.  Or maybe big hairy gobs of free time.  Or even big hairy
undulating gobs of free time.  Then again, maybe it's too early in the
morning for this discussion. :-)>

 - MichaelH
...........................................................................

Fm: Lary Myers 76004,1574                      # 383466
To: Bart Stewart 76247,1130 (X)                Date: 24-Jun-93  23:33:01

Bart - You hit the nail on the head about the primitive object handling! I am
almost embarressed to admit that I wrote that code! One of the things I had
in mind when starting the engine was to have separate "modes" for
interaction. In the movement or normal mode, the mouse would turn you around
and allow forward and reverse movement. By toggling out of that mode into
another, the mouse would then become a pointer that could be used for object
selection, menus/icons, etc. While I haven't implemented this yet, that was
the original reason the engine stayed at full screen. The interactive mode
would overlay the screen only when needed and then be out of the way when
actually moving around. Might not be the right way to go, but one thing I've
noticed about the UW2 screen is that the area where you actually move feels
cramped and small at times. It seems I'm almost squinting to look up in the
upper left corner to see where to go, etc. Some of this is due to the very
nice effect of darker walls in the distance, but some is due to the size of
the area. Maybe someone can come up with a variety of prototypes for screen
areas. Even text screens with boxes to show what would be displayed where
would be useful. I will look at making the engine more generic in how much is
displayed on the screen - heck, the smaller the area, the faster it will be!
Thanks for the comments - Lary
...........................................................................

Fm: Frank Sachse 74140,2413                    # 383125
To: Lary Myers                                 Date: 24-Jun-93  14:40:00

Sounds fine by me.

BTW your recent changes only affect the map storage & not the size of the
bitmaps, etc.?  In other words can we use the graphics from ACK3D v1.0 as a
template of sorts for creating new graphics?

BTW how often would new versions be released?  And what is the designation
for the current version?  1.0?

As for sound, I have the Worx lib, but that may not help here since I could
only upload the engine as an exe.  To upload the source wouldn't everyone
have to get the Worx lib too?  Is there another way we can add
voc/cmf/mid/etc support to get around that?  Using SBF.zip (lib 11)? I'd be
willing to add the Worx stuff.  Don't know much about other methods, ie. SBF,
etc..

I will also be working on some additional graphics, especially outdoor
oriented.

- Frank

PS my kids also enjoy your maze...
...........................................................................

Fm: Frank Sachse 74140,2413                    # 383130
To: Lary Myers                                 Date: 24-Jun-93  14:55:37

Ok, put me down for:

1) bitmaps - mostly outdoor, but some indoor too 3) sounds - vocs, right?
any special considerations, ie. sample rate, duration?

Count me in.  Will upload to you as soon as I get anything...

- Frank
...........................................................................

Fm: Lary Myers 76004,1574                      # 383470
To: Frank Sachse 74140,2413                    Date: 24-Jun-93  23:35:51

Okay Frank, you are officially marked down for the following:

Bitmaps (mostly outdoor and some indoor).

Sounds - Yes VOC is used right now, what about MOD files??? The sampling rate
in use now was 11000 but thats not fixed in concrete.

Thanks Frank! :)

Lary
...........................................................................

Fm: Bart Stewart 76247,1130                    # 383154
To: Lary Myers                                 Date: 24-Jun-93  16:09:42

  Lary, I've run across a problem.
  When trying to grok someone else's code, I normally compile what they wrote
before I ever make any changes. That gives me a baseline with which to
compare my changes.   The ACK3D code isn't cooperating. <g>
  I'm doing my compilation using the Borland IDE, rather than your Make
program, under BC++ 3.1. Several of your source files are generating
warnings. The two most common warnings are "Suspicious pointer conversion"
(which seems to show up in lines mixing "far" and "near" data types), and
"Conversion may lose significant digits". This second one really makes me
nervous. It shows up in several places where you're doing math on ints, or
shifting longs to ints and masking, then assigning the result to longs. I can
go in and typecast to (long), but it's difficult to know whether that's what
you intended there.   So. Let me see if I've got this right... You're using
the compact memory model, optimizing for speed, and your char type defaults
to "signed", yes?
  -- Bart
...........................................................................

Fm: Lary Myers 76004,1574                      # 383463
To: Bart Stewart 76247,1130 (X)                Date: 24-Jun-93  23:25:02

Bart - Yes, your correct about compact model and signed ints. I am not
getting those warnings, but I need to check my config file here in a bit and
see if I have any warnings turned off, I don't believe so but.... Can you
upload an error listing from the compile so I can look at the line numbers
where the warnings occur? I'll get back on the intented purpose of the lines
and if the warnings are "acceptable" or not. I'll also let you know what my
warning/error reporting level is set to in Borland C V3.1 - Thanks for the
info.
Lary
...........................................................................

Fm: Bart Stewart 76247,1130                    # 383506
To: Lary Myers 76004,1574 (X)                  Date: 25-Jun-93  00:30:22

  Lary, I can't upload warnings now, because I got impatient, and went in and
changed the code. <grin> It compiles fine, now that I'm doing a bit of
typecasting.
  Unfortunately, I've learned that it sucks up so much RAM that neither Turbo
Debugger nor Turbo Profiler will work with ACK3D.EXE. Sigh.
  -- Bart
...........................................................................

Fm: Lary Myers 76004,1574                      # 383532
To: Bart Stewart 76247,1130                    Date: 25-Jun-93  01:07:29

Okay Bart, I was just sending a message your way that I don't have any
special switches in TURBOC.CFG so I'm not sure why the warnings occur, but if
you got them fixed then you can move forward anyway.... (Still curious
though).
Lary
...........................................................................

Fm: Kris Pelley 72763,2357                     # 383382
To: Larry Myers                                Date: 24-Jun-93  21:58:06

I have a few questions/suggestions for ACK stuff...

First off, you wanted to add moving objects/actors to the engine. Since your
modeling off of Wolfenstein why not use their method for moving the actors
around, ie: place invisible (non-barrier) objects that act as movement
directors for your objects/actors, then have the objects/actors in motion as
the game starts (or add trigger objects), then when the object/actor bumps
into one of the 'directional' objects he changes his direction of movement
according to the directional object he walks onto. The following/retreating
algorithms I have no ideas on, but I think I saw an article in DDJ a while
back about using genetic algorithms to solve mazes. If you used the players
position as the exit of the maze, you could have a genetic algorithm plot the
fastest course around walls, objects, etc. to get to the player. The
retreating algortihm could be just the opposite...

The other topic is sound. VOC/CMF-VOICE.DRV stuff only works with single
channel output (I thought...), so this could be a problem if you want to have
more than sample playing at the same time. Why not go the route of MOD
players and set up an interrupt for playing sound, and just output to the SB
hardware directly. Then you could have MOD music playing, and multi-channel
sound effects (or just the sound effects).
Kris
...........................................................................

Fm: Lary Myers 76004,1574                      # 383456
To: Kris Pelley 72763,2357                     Date: 24-Jun-93  23:18:45

Thanks for the comments Kris. I am aware of the Wolf style of movement
squares and have it in the back of my mind as one possibility for moving
objects. I like your idea about follow/retreat with the player at the end of
the maze. Any idea on the speed such algorithms would have? Anyone?

The MOD interrupt driver is definitely the way to go from your description, I
have some idea on how to program the SB directly, but what would the file
format be and would it be virtual or all read into memory?

Lary
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 383487
To: Kris Pelley 72763,2357                     Date: 24-Jun-93  23:57:13

Hi, Kris. I bet the AI for Wolf3D is ridiculously simple. Find player, shoot
at player <g>.
                                                        --Mark
...........................................................................

Fm: Frank Sachse 74140,2413                    # 383442
To: ALL                                        Date: 24-Jun-93  23:03:51

This may sound like a dumb question, but how do I load .img files into DP2e?
I have no problem with .lbm & .bbm Do I have to convert them first, then
reconvert them afterward (in order to produce .img)?  Use something else?
Please advise.  Thanks!

- Frank, the novice (still)...
...........................................................................

Fm: Lary Myers 76004,1574                      # 383460
To: Frank Sachse 74140,2413                    Date: 24-Jun-93  23:20:38

Frank - Not a dumb question, but here is the lame answer - You can't! I
created the IMG files in the opposite direction, by using DP2 to draw the
picture and then a capture program to block out the 64x64 area and save it to
a file. The reverse cannot be done, that would fall under the category of one
of the utilities we need yet.

Lary
...........................................................................

Fm: Mark Betz/Ass't SysOp 76605,2346           # 383490
To: all                                        Date: 24-Jun-93  23:57:20

The following new files are now available in LIBRARY 11 (Game Design):

[76004,1574]
ACK3D.CON/Asc     29646    24-Jun-93

  Title   : ACK3D Conference Transcript (Text)
  Keywords: ACK 3D ENGINE VGA GRAPHICS RAYCAST CON TEXT

  Transcript of the first 3D conference held June 17th in the Game Design
  Conference Room. ASCII Text. Read online or download. Also, don't miss the
  source to the ACK3D raycasting engine in the files ACKSRC.ZIP and
ACKKIT.ZIP   in LIBRARY 11 (Game Design).

...........................................................................